Runtime detector for data corruptions

ABSTRACT

In a multitenant data platform architecture, one or more supporting data tables are used to efficiently retrieve data responsive to data retrieval requests. Programmatic code markers associated with contextual data about a data transaction thread are identified. The contextual data is examined using the one or more programmatic code markers invoked by the database in the data transaction thread at runtime. Based on the contextual data returning an indication of a data corruption in one or more supporting data structures, an action associated with the data transaction thread is performed. A log of data corruptions and corresponding call stack trace data may be generated. The data transaction thread may be allowed to continue to execute statements that modify data tables, or the data transaction thread may be terminated.

TECHNICAL FIELD

The present invention relates generally to cloud-based data retrieval,and in particular, to a runtime detector for identifying datacorruptions in custom indexes and other data structures that supportdata retrieval processes.

BACKGROUND

A large-scale cloud-based computer system may include multipledatacenters at various geographic locations to maintain millions of setsof application data for millions of organizations as well as providemillions of sets of application services such as those for customerrelationship management (CRM), secured data access, online transactionprocessing, mobile apps, etc., to respective users and/or customers ofthese organizations.

Architecturally, the large-scale cloud-based computer system may rely ona multitenant architecture that employs standard objects while usingcustom indexes and other data structures that are used to store andretrieve customer data. However, over time, data corruptions may preventa tenant from accessing correct data.

Custom indexes and “skinny tables” are meta structures used by processesto generate efficient database queries in response to a tenant's datafetch requests in a multitenant data platform architecture. A corruptcustom index or a corrupt skinny table means that correct data cannot bereturned to a tenant (or customer/organization), resulting in asignificant trust issue. A skinny table may also be referred to as auser-specified view of data stored in a multitenant data platformarchitecture generated at runtime.

Even through close and intensive human supervision from expertsexperienced in various aspects relating to manually identifyingcorruptions, new data corruptions continue to surface. Manual searchesfor data corruptions results in errors, inefficient use of resources,lack of transparency, prolonged downtimes, and organization-widefailures. Maintenance code generated to reduce corruptions, such astrigger maintenance, also fails to capture corruptions existing outsidethe maintenance code. Significant time and resources are spent on acontinuing basis to address data corruption at runtime.

The approaches described in this section are approaches that could bepursued, but not necessarily approaches that have been previouslyconceived or pursued. Therefore, unless otherwise indicated, it shouldnot be assumed that any of the approaches described in this sectionqualify as prior art merely by virtue of their inclusion in thissection. Similarly, issues identified with respect to one or moreapproaches should not assume to have been recognized in any prior art onthe basis of this section, unless otherwise indicated.

BRIEF DESCRIPTION OF DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1A illustrates an example overall data corruption runtime detectionframework; FIG. 1B and FIG. 1C illustrate an example configuration fordata objects in a multitenant data platform architecture;

FIG. 2 illustrates an example high-level block diagram, including anexample corruption detecting platform;

FIG. 3 illustrates an example process flow;

FIG. 4 illustrates an example process flow; and

FIG. 5 illustrates an example hardware platform on which a computer or acomputing device as described herein may be implemented.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however,that the present invention may be practiced without these specificdetails. In other instances, well-known structures and devices are notdescribed in exhaustive detail, in order to avoid unnecessarilyoccluding, obscuring, or obfuscating the present invention.

Example embodiments are described herein according to the followingoutline:

-   -   1.0. General Overview    -   2.0. Functional Overview    -   3.0. Example Embodiments    -   4.0 Implementation Mechanism—Hardware Overview    -   5.0. Extensions and Alternatives

1.0 General Overview

This overview presents a basic description of some aspects of anembodiment of the present invention. It should be noted that thisoverview is not an extensive or exhaustive summary of aspects of theembodiment. Moreover, it should be noted that this overview is notintended to be understood as identifying any particularly significantaspects or elements of the embodiment, nor as delineating any scope ofthe embodiment in particular, nor the invention in general. Thisoverview merely presents some concepts that relate to the exampleembodiment in a condensed and simplified format, and should beunderstood as merely a conceptual prelude to a more detailed descriptionof example embodiments that follows below.

Techniques as described herein can be used by a corruption detectionplatform to identify data corruptions in custom indexes and/or skinnytables at runtime upon execution of a data retrieval request (e.g.,while building a query). Data tables are data structures that hold datarepresenting an entity. A custom index is a meta structure similar to astandard index and is used by a query builder to successfully access atenant's data. A skinny table is a meta structure which is a copy ofdata representing an entity for a given organization. Both customindexes and skinny tables are used by the query builder in response to atenant's data fetch requests. In this way, the term “supporting tables”may be used to refer to both custom index tables and skinny tablesbecause both support the query builder in efficiently responding to adata retrieval request. A corrupt custom index or a corrupt skinny tableindicates that correct data cannot be returned to a tenant (e.g.,customer or organization). Detecting corruption in custom indexes and/orskinny tables is performed by the corruption detection platform atruntime.

Data retrieval requests as described herein represent a large part ofnormal operations in the computing system—which may host a relativelylarge number of organizations or tenants—based on the applications thatoperate on the computing system. Context is identified by the corruptiondetection platform. Here, context is a programmatic marker to mark thebeginning and the end of any named code block(s). For example, atransaction context has a beginning and an ending, encompasses all thecode and/or SQL statement in between, and is treated as a whole. Actionsthat happen in a context have context-awareness, meaning that theactions are known to have happened within the specified context, eitherdirectly or indirectly. Additionally, optionally or alternatively,context may be associated with one or more threads of execution. In anembodiment, the context is single-threaded and limited to the currentthread and current transaction. The detector code, executed uponestablishing the context, has no operative functions becauseestablishment of the context implies a correct and complete invocationof the requested data. However, when the detector code queries and findsthe context to be absent, incorrect invocation is implied and thedetector code executes one of the associated actions.

It should be noted that corruption detections as described herein canoperate in conjunction with other system functions relating to dataretrieval, query building and/or query optimizing of the system, butthere is no need for the corruption detection platform to be used todirectly provide these other system functions.

A corruption detection platform as described herein operates at runtimeupon receiving a data fetch request from a tenant. A callback hook isused to register and initialize a context. Used here, a callback hook isa piece of programmatic code, including code markers, that passes alongcode to be executed. The callback hook is invoked by the database priorto execution of statement(s) that would insert, update, or delete data(data manipulation language, also known as a “dml operation”) in atarget table. Traditionally, a transaction that involves a dml operationrepresents a set of operations that are executed as a single unit. AllDML operations in a transaction either complete successfully, or if anerror occurs in one operation, the entire transaction is rolled back andno data is committed to the database. The boundary of a transaction canbe a trigger, a class method, an anonymous block of code, aspecially-designed page for the multitenant architecture, or a customweb service method. In short, these programmatic code markers delineatethe boundaries of the transaction.

Context, (e.g., execution context, or contextual data), is then examinedusing the callback hook. If the context is found set, meaning that thecontext is properly registered and initialized, then the context isflagged to allow the current invocation, and the dml operation againstthe table is allowed to proceed. Otherwise, if the context is not foundwhile being examined or if the context cannot be registered andinitialized, then either the call stack trace is logged in a table or inmemory along with the current execution, or the current transaction isfailed by the corruption detection platform.

A separate process, either through an application programming interface(API) or a scheduled process, polls this table and/or memory, removesduplicates, and presents the corrupting call stacks to a user of theplatform.

A platform user, who may be an operator, an administrator, an authorizeduser, a designated user, etc., for identifying data corruptions, cansend or issue a request for data corruptions affecting one or moreorganizations, for example through a web portal or a web page, to thelog presenter.

An organization may comprise various components (e.g., HBase, FileForceor FFX, etc.) each of which contains application data and applicationservices. As used herein, a component refers to a system of record thatcontains its respective application data (e.g., organization-specificapplication data, organization-common application data, customer data,FFX, HBase, etc.) and/or its respective application services (e.g.,organization-specific application services, organization-commonapplication services, customer applications, mobile apps, cloud-basedapplications, backend program logics, etc.). The corruption detectingplatform can implement a plug-and-play framework that allows differentengineers respectively responsible for different components to develop,maintain, test and/or experiment respective organization specific codeto be executed for different state transitions (e.g., different stages,different phases, etc.) throughout the course of data retrievaloperations.

Various modifications to the preferred embodiments and the genericprinciples and features described herein will be readily apparent tothose skilled in the art. Thus, the disclosure is not intended to belimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features described herein.

2.0 Functional Overview

FIG. 1A illustrates an example overall data corruption runtime detectionframework 100 for detecting corrupted tables in a computing system.Example computing systems that implement the data corruption runtimedetection framework (100) may include, but are not necessarily limitedto: any of: a large-scale cloud-based computing system, a system withmultiple datacenters, multitenant data service systems, web-basedsystems, systems that support massive volumes of concurrent and/orsequential transactions and interactions, database systems, and soforth. Various system constituents may be implemented through software,hardware, or a combination of software and hardware. Any, some or all ofthese system constituents may be interconnected and communicateddirectly, or through one or more networks 120.

A user device 126 may communicate with a computing system through one ormore networks 120. A viewing user may interact with data in thecomputing system using the user device 126 through a user interface 128.For example, a salesperson may update a data value for a potential salesopportunity through the user interface 128. The salesperson may be auser within a specific organization that has thousands of recordsassociated with opportunities. Upon requesting to modify a data value ofa particular opportunity record, a query builder 104 may generate one ormore call statements that facilitates access to the data within theopportunity record. The multitenant data platform architecture of thecomputing system uses one or more custom index tables and/or skinnytables to provide quick access to the data stored within the computingsystem at the data store 112.

As illustrated in FIG. 1A, an organization (“org”) 150 may use one ormore custom indexes 106, one or more skinny tables 108, and one or moreviews of org data by user 110 to provide faster access to data uponreceiving a data fetch request. At run time, the one or more customindexes 106 and/or one or more skinny tables 108 may be instantiated orinvoked. If a table becomes corrupted, the corrupted status becomesdetectable upon a call statement attempting to invoke the table. Thus,the runtime corruption detector 102 uses a context examiner 114, atransaction handler 116, and a call stack trace logger 118 to identifycorrupted tables and handle them appropriately. The runtime corruptiondetector 102 generates a callback hook associated with a skinny tablewhen detecting corruptions in the skinny table. In another embodiment,the runtime corruption detector 102 uses the callback hook alreadyassociated with a custom index table when detecting corruptions in thecustom index table.

A runtime corruption detector 102 uses a context examiner 114 to enablethe runtime corruption detector 102 to understand the context of a codeblock. As mentioned above, context is understood to be a programmaticcode marker that signifies a beginning and/or an ending of any codeblock. A context may have a name, such as a transaction context. Actionsthat occur within a context have knowledge of the context, eitherdirectly or indirectly. This means that an action that occurs within acontext will have knowledge that the action is associated with thecontext.

A transaction handler 116 generates actions to be performed when acorruption is detected. Several actions may be performed once acorruption is detected; the callback hook may be flagged and logged,however the transaction may be allowed to proceed, ignoring the context,to minimize disruption to the user experience. In another embodiment,after detecting a corrupted table, an action that may be performedincludes failing or terminating the transaction. In yet anotherembodiment, an administrative user may generate a set of rules todetermine which actions are to be performed when a corruption isdetected. The set of rules may include deference to high prioritytransactions, high level accounts, and/or other important cases wheretransactions should be allowed to proceed even where a data corruptionis found. In further embodiments, administrative users may selectivelychoose to create rules where actions are to be performed based oncontext gathered within the transaction.

A call stack trace logger 118 generates a record of the call stack tracethat led to the detected corruption in a log store 122. A log examiner124 may later be used to analyze the log records generated by the callstack trace logger 118. The log examiner 124 may be a separate processthat, through an application programming interface (API) or in ascheduled process, enables a user of the corruption detection platformframework 100 to access the log records.

FIG. 1B and FIG. 1C illustrate an example configuration for data objectsin a multitenant data platform architecture. Conventional data objectsare stored persistently in a database. However, data objects in amultitenant data platform architecture include metadata such thatobjects may be standardized for all tenants within the multitenant dataplatform architecture, while also enabling tenants to add custom fieldsand other data objects that describe the relationships between dataobjects. As a result, traditional performance tuning techniques do notyield the same results on data objects in a multitenant data platformarchitecture. Instead of managing a vast, ever-changing set of actualdatabase structures for each application and tenant, the multitenantdata platform architecture utilizes a platform storage model thatmanages virtual database structures using a set of metadata, data, andpivot tables. When organizations create custom objects, the platformtracks metadata about the objects and their fields, relationships, andother object definition characteristics. The application data for allvirtual tables for all organizations are stored in a few very largedatabase tables, which are partitioned by tenant and help serve as heapstorage. The platform's engine then materializes virtual table data atruntime by considering the following metadata. As shown in FIG. 1B,standard objects 130 are associated with storage for standard datafields. An example standard object 130 is an account object 162, shownin FIG. 1C. Standard fields may be stored in a standard fields table 172in a database 170. Returning to FIG. 1B, standard objects custom fields132 are associated with storage for custom fields on standard objects.An example of a custom field on a standard object is illustrated in FIG.1C as a “Region” custom field on the account object.

Custom objects 134 are associated with storage for all fields on customobjects. An example of a custom object may be an object relating citiesto zip codes in the US. Indexes 136 include data objects that act aspivot tables for indexing fields. Fields 138 include data objects thatact as pivot tables to enforce unique fields. Relationships 140 includedata objects that act as pivot tables for foreign keys. Other dataobjects may be used in the platform's storage model for storing andretrieving data values in the multitenant data platform architecture.

FIG. 1C illustrates an example account object, a standard object, thatincludes custom fields and is combined for a particular user's view 160.The user view of the account object 160 includes standard object fieldsof the account object: Account Name, Employees, Industry, and Website.Also included in the user's view of the Account object are customfields: Region, District, and Previous Customer. Two tables in adatabase 170 store the data values of the fields included in the accountobject. The data values of the custom fields are stored in a separateAccount Custom Fields table 174. The data values of the standard fieldsare stored in the Account Standard Fields table 172. These two tablesare used for all data values from all orgs. An account skinny table 176includes selected fields from the two tables per org and per object:Account Name, Employees, Industry, Website, and Region. The skinny tableis a copy of the underlying data and is generated at runtime tofacilitate faster access to the data. However, data corruptions arisebecause multiple custom indexes and/or multiple skinny tables may beused to support efficient retrieval of data in the multitenant dataplatform architecture.

Data corruptions may take many different forms. Data may be missing fromthe supporting data structures (e.g., virtualized database structuresmentioned above, etc.). In other embodiments, data may be in a wrongformat, or not normalized. For example, capitalized names of accountsmay be normalized to lower case names. In any case, data corruptionslead to a disrupted user experience, causing a lack of user trust.Identifying data corruptions has also been traditionally difficultbecause of the platform storage model described above and issues relatedto multitenancy. By registering and identifying data corruptions atruntime and logging the call stack trace, or call graph, the log recordsdetailing the data corruptions may be further examined in a separateprocess and/or API. In an embodiment, other processes may be used tocompensate and/or correct these data corruptions. For example, a usermay rollback data in a table to retrieve lost data. As another example,complex algorithms and programmable logic may be used to correct theformat of this data to compensate for non-normalized data values causinga data corruption. A further example of a way to correct or compensatefor data corruptions is a debug program that detects writes or changesto a table. The context may be examined in an asynchronous manner toidentify a call stack trace that led to the data corruption.

FIG. 2 illustrates an example high-level block diagram, including anexample corruption detecting platform. In some embodiments, thecomputing system that hosts the organizations may comprise a pluralityof datacenters such as 212-1, 212-2, 212-3, etc., as illustrated in FIG.2, which may be located at the same or different geographic locationssuch as the same or different continents, the same or differentcountries, the same or different states, the same or different regions,and so forth.

Each data center may implement a set of system instances to hostrespective organizations. These organizations may contract with theowner of the computing system such as a multitenant computing system tohost their respective (e.g., organization-specific, organization-common,etc.) application data, to provide their (e.g., organization-specific,organization-common, etc.) application services to their respectiveusers and/or customers. Examples of application data may include, butare not limited to, organization-specific application data,organization-common application data, application configuration data,application data, application metadata, application code, etc.,specifically generated or configured for (e.g., organization-specific,organization-common, etc.) application services of an individualorganization, etc.

As used herein, the term “organization” may refer to some or all of(e.g., complete, original, a non-backup version of, a non-cached versionof, an online version of, original plus one or more backup or cachedcopies, an online version plus one or more offline versions of, etc.)application data of an organization hosted in the computer system andapplication services of the organization based at least in part on theapplication data.

As illustrated in FIG. 2, each datacenter (e.g., 212-1, 212-2, 212-3,etc.) may comprise a set of one or more system instances. A firstdatacenter 212-1 comprises first system instances 210-1-1, 210-1-2,etc.; a second datacenter 212-2 comprises second system instances210-2-1, 210-2-2, etc.; a third datacenter 212-3 comprises third systeminstances 210-3-1, 210-3-2, etc.

Each system instance (e.g., 210-1-1, 210-1-2, 210-2-1, 210-2-2, 210-3-1,210-3-2, etc.) in the hosting computing system can host up to a maximumnumber of organizations such as 5,000 organizations, 10,000organizations, 15,000+ organizations, etc. As illustrated in FIG. 2, thesystem instance (210-1-1) in the datacenter (212-1) may host a firstorganization 214-1 and a second organization 214-2, among others; thesystem instance (210-1-1) in the datacenter (212-1) may host a thirdorganization 214-3, among others.

FIG. 2 illustrates an example corruption detecting platform 200 thatprovide reliable, flexible and scalable protection against datacorruptions affecting data retrieval in the computer system. In someembodiments, corruption detections can be performed fully automatically.In some embodiments, a user can choose to specify and perform a (e.g.,large, etc.) corruption detection automatically with some manuallyperformed actions, such as flagging the corrupted table in a log andhaving users inspect the logs through a separate process. An examplecorruption detecting platform 200 includes an API manager 202, a logpresenter 204, a query builder 104, a runtime corruption detector 102,and a log data store 122, in an embodiment. Thus, the corruptiondetecting platform 200 can be used to avoid a manual, lengthy, andburdensome corruption detection process that relies on relatively heavycross-discipline involvement and cooperation from different personneland teams over long time periods such as months to monitor, identify,correct, reestablish functionality, etc.

A user such as an operator, an administrator, an authorized user, adesignated user, and so forth, can use a user device 126 to enter orsend a request for a listing of detected data corruptions to bepresented through an application programming interface (API) provided byan API manager 202 or another interface provided by a log presenter 204.The user device 126 may be operatively linked to, and communicate with,the corruption detecting platform 200 through one or more networks(e.g., 120, etc.) or via a local data connection.

Upon receiving the request for a listing of detected corruptions, thelog presenter 204 can automatically generate a listing of call stacktraces that led to each detected corruption in a custom index table orskinny table for an organization by object. For each organization, thelog presenter 204 may identify where the specific organization (e.g.,the first organization (214-1), etc.) is instantiated (e.g., the systeminstance (210-1-1) in the first datacenter (212-1), etc.), as well asother information related to the specific organization. For example,configuration data, any commands and/or operational parameters set forthfor the requested organization, etc., may be gathered and provided bythe log presenter 204, in an embodiment. By providing a listing of callstack traces by object, the performance of the computing system isgreatly improved because problems, such as corruptions in data tables,are identified by the system automatically and may be presented to auser upon request, in an embodiment. The log presenter 204 furtherenables other processes and users to become aware of data corruptionsfaster, further increasing the reliability and functioning of thecomputing system because data corruptions can be addressed faster,either automatically or manually by administrative users.

At runtime, runtime corruption detector 102 operates with a querybuilder 104 in identifying data corruptions in custom indexes and/orskinny tables and carrying out the specified actions for the identifieddata corruption(s). These corruption specific actions are automaticallyperformed (e.g., flagging the data corruption and allowing thetransaction thread to continue to execute or failing the transactionthread), thereby causing the query builder 104 to continue to buildtables at runtime with no or minimal/minor human intervention (e.g., innormal operational scenarios, etc.).

Additionally, optionally or alternatively, as a part of the continuousdata corruption detection, the corruption specific actions automatically(e.g., fully automatically, automatically with a manual part specifiedor performed by a user, etc.) performed under techniques as describedherein can cause system configuration data, system data, systemmetadata, system code, etc., to be (e.g., fully automatically, withminimal manual input, etc.) generated and deployed in connection withthe affected system instance (210-1-1) and/or the affected datacenter inthe present example. As used herein, system configuration data, systemdata, system metadata, system code, etc. refers to system-level dataand/or system-level services used to store, access, or manipulate theapplication data for the organization, to enable the applicationservices, etc.

In contrast with a monolithic system containing all heavy liftingpotentially convoluted program logic for performing corruption detectionin tables as under other approaches, the system configuration asillustrated in FIG. 2 provides a highly efficient, scalable, extensibleinfrastructure for orchestrating and performing multiple differentcorruption detections, while leaving implementation details including,but not limited to, detected corruption steps for each table componentin an affected organization to engineers and experts for each such tablecomponent. The system configuration provides an infrastructure that canbe efficiently scaled up to a relatively large number (e.g., 100,000,etc.) of detected corruptions with (e.g., optimal, etc.) minimizeddowntime and with no or minimal human intervention, as the datacentersand the system instances therein continue to scale up, and/or asorganization-specific and organization-common application data andapplication services of respective organizations continue to spread intomore and more (e.g., disparate, etc.) types of systems of records,system instances, databases, datacenters, and/or as engineering teamscontinue to develop respective products and features for differentcomponents (or systems of record) and make new releases of theseproducts and features.

The infrastructure supports relatively stable and well-definedinterfaces (e.g., application programming interfaces or APIs, classinterfaces, table component and/or step registries etc.) comprising(e.g., abstract, default, skeleton, etc.) methods, data items, datatypes, and so forth, to be specifically implemented by the engineers foreach table component. The infrastructure also provides or implements atable component and/or step registration mechanism for registeringto-be-fixed custom index table or skinny table components and/or stepsfor the components. The infrastructure can support fault tolerance andrelatively high resilience in data corruptions. For example, non-fatalerrors in migration specific actions or steps and/or stalledoperations/steps can be recovered or resolved by skipping or retryingthese actions, operations or steps for a limited number of times orindefinitely and/or by implementing alternative solutions (e.g.,workarounds, manual operations, temporary solutions, expedientsolutions, etc.). The infrastructure can be used to collect (e.g.,realtime, near-realtime, etc.) progresses of corruption specific actionsor steps in response to any given data corruption and present anup-to-date consistent view and/or a call trace history of each detectedcorruption as stored in the log data store 122. In addition, theinfrastructure can be used to support parallel (or in any order)executions of multiple different corruption specific actions or steps ina single code block or multiple different code blocks, so long as anydependency relationships between components and actions are respected ormaintained.

In various embodiments, any of, some, or all combinations of a pluralityof data storage facilities (e.g., the log data store 122, etc.), aplurality of data representations, etc., including, but not limited to,message-queue-based data storage facilities and/or representations,data-relational-object-based data storage facilities and/orrepresentations, cookie-based data storage facilities and/orrepresentations, etc., can be used to represent or store callback tracelog data portions for a table component and/or any corrective step inresponse to a detected corruption in a table component. By way ofexample but not limitation, corrective steps for delayed execution canbe persisted in a data storage facility or a data repository such as thelog data store 122.

The corruption detecting platform 200 may be implemented (e.g., as aprogram object, as a class object, etc.) with a context flagging processto generate log records in the log data store 122 for identified datacorruptions that need manual intervention for correction. The contextflagging process may determine, after a context is invoked, whether aflag is required to identify a detected corruption. Because custom indextables and skinny tables are generated at runtime to assist a querybuilder 104 in formulating efficient database queries, context flaggingis needed to catch corrupted custom index tables and skinny tables andidentify the call stack traces that led to the corrupted tables. Contextflagging is also referred to as contextual data herein.

The corruption detecting platform 200 implements program logicresponsible for logging (e.g., system logs, traces, etc.) detectedcorruptions of custom index tables and/or skinny tables through theruntime corruption detector 102. The log presenter 204 may beimplemented as a program class/object to support or allowconsumptions/manipulations of detections of corrupted custom indextables and/or skinny tables by interested program classes/objects (e.g.,processes, threads, objects, classes, interfaces, instantiations,implementers, methods, etc.) that are interested in such detections. Forexample, a user using a user device 126 may be interested in querying,through log presenter 204, the detections of corrupted tables in orderto present the corrupted tables to an operator and then obtain userinput from the operator with respect to any failures or issues inrelation to these detections. It may be determined whether any steps tocorrect or compensate for data corruptions have completed successfullyor failed, or whether any actions have been skipped by operators, and soforth. The log presenter 204 may operate as a separate process or as anapplication programming interface (API).

3.0 Example Embodiments

FIG. 3 illustrates an example process flow that may be implemented by acomputing system (or device) as described herein. In block 302, aruntime corruption detector 102 (e.g., 102 of FIG. 1A, etc.) identifiesa context using a callback hook where the context is invoked by adatabase prior to executing instructions to modify a target table.

In block 304, for a current custom index table that is being examined,it is determined from the context whether a data corruption exists. Thismeans that if the context is properly found to be invoked, then there isno data corruption. In this case, no other action is performed, and therequest to modify the target table is allowed to proceed.

In block 306, based on the data corruption existing in the currentcustom index table, the transaction is configured to fail by the runtimecorruption detector 102. The action here performed is configuring, ormarking, the transaction to fail because the transaction is alsooccurring in real-time, or substantially at the same time as block 306of the process illustrated in FIG. 3. In some embodiments, block 306 isoptional. If the current transaction is configured to fail, the currenttransaction thread fails and the request to modify the target table isdenied.

In block 308, the transaction is configured to be logged based on thedata corruption existing in the current custom index table. A call stacktrace is logged in conjunction with the identified data corruption inthe current custom index table.

FIG. 4 illustrates another example process flow that may be implementedby a computing system (or device) as described herein. In block 402, aruntime corruption detector 102 (e.g., 102 of FIG. 1A, etc.) identifiesa context invoked by a database prior to executing instructions tomodify a target table.

In block 404, for a current skinny table that is being examined, acallback hook is created that identifies the current skinny table in thesystem and it is determined from the context whether a data corruptionexists. Because skinny tables are created at runtime, a callback hook iscreated to identify the current skinny table. If the context is properlyfound to be invoked, then there is no data corruption. In this case, noother action is performed, and the request to modify the target table isallowed to proceed.

In block 406, the current transaction is configured to fail based on thedata corruption existing in the current skinny table. In someembodiments, block 306 is optional. If the current transaction isconfigured to fail, the current transaction thread fails and the requestto modify the target table is denied.

In block 408, the transaction is configured to be logged based on thedata corruption existing in the current skinny table. Here, thetransaction is configured, or marked, to be logged because thetransaction is executing simultaneously or substantially at the sametime as block 408 of the process illustrated in FIG. 4. A call stacktrace is logged in conjunction with the identified data corruption inthe current skinny table.

In some embodiments, process flows involving operations, methods, etc.,as described herein can be performed through one or more computingdevices or units.

In an embodiment, an apparatus comprises a processor and is configuredto perform any of these operations, methods, process flows, etc.

In an embodiment, a non-transitory computer readable storage medium,storing software instructions, which when executed by one or moreprocessors cause performance of any of these operations, methods,process flows, etc.

In an embodiment, a computing device comprising one or more processorsand one or more storage media storing a set of instructions which, whenexecuted by the one or more processors, cause performance of any ofthese operations, methods, process flows, etc. Note that, althoughseparate embodiments are discussed herein, any combination ofembodiments and/or partial embodiments discussed herein may be combinedto form further embodiments.

4.0 Implementation Mechanisms—Hardware Overview

According to one embodiment, the techniques described herein areimplemented by one or more special-purpose computing devices. Thespecial-purpose computing devices may be hard-wired to perform thetechniques, or may include digital electronic devices such as one ormore application-specific integrated circuits (ASICs) or fieldprogrammable gate arrays (FPGAs) that are persistently programmed toperform the techniques, or may include one or more general purposehardware processors programmed to perform the techniques pursuant toprogram instructions in firmware, memory, other storage, or acombination. Such special-purpose computing devices may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toaccomplish the techniques. The special-purpose computing devices may bedesktop computer systems, portable computer systems, handheld devices,networking devices or any other device that incorporates hard-wiredand/or program logic to implement the techniques.

For example, FIG. 5 is a block diagram that illustrates a computersystem 500 upon which an embodiment of the invention may be implemented.Computer system 500 includes a bus 502 or other communication mechanismfor communicating information, and a hardware processor 504 coupled withbus 502 for processing information. Hardware processor 504 may be, forexample, a general purpose microprocessor.

Computer system 500 also includes a main memory 506, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 502for storing information and instructions to be executed by processor504. Main memory 506 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 504. Such instructions, when stored innon-transitory storage media accessible to processor 504, rendercomputer system 500 into a special-purpose machine that isdevice-specific to perform the operations specified in the instructions.

Computer system 500 further includes a read only memory (ROM) 508 orother static storage device coupled to bus 502 for storing staticinformation and instructions for processor 504. A storage device 510,such as a magnetic disk or optical disk, is provided and coupled to bus502 for storing information and instructions.

Computer system 500 may be coupled via bus 502 to a display 512, such asa liquid crystal display (LCD), for displaying information to a computeruser. An input device 514, including alphanumeric and other keys, iscoupled to bus 502 for communicating information and command selectionsto processor 504. Another type of user input device is cursor control516, such as a mouse, a trackball, or cursor direction keys forcommunicating direction information and command selections to processor504 and for controlling cursor movement on display 512. This inputdevice typically has two degrees of freedom in two axes, a first axis(e.g., x) and a second axis (e.g., y), that allows the device to specifypositions in a plane.

Computer system 500 may implement the techniques described herein usingdevice-specific hard-wired logic, one or more ASICs or FPGAs, firmwareand/or program logic which in combination with the computer systemcauses or programs computer system 500 to be a special-purpose machine.According to one embodiment, the techniques herein are performed bycomputer system 500 in response to processor 504 executing one or moresequences of one or more instructions contained in main memory 506. Suchinstructions may be read into main memory 506 from another storagemedium, such as storage device 510. Execution of the sequences ofinstructions contained in main memory 506 causes processor 504 toperform the process steps described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions.

The term “storage media” as used herein refers to any non-transitorymedia that store data and/or instructions that cause a machine tooperation in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical or magnetic disks, such as storage device 510.Volatile media includes dynamic memory, such as main memory 506. Commonforms of storage media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 502. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 504 for execution. For example,the instructions may initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 500 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 502. Bus 502 carries the data tomain memory 506, from which processor 504 retrieves and executes theinstructions. The instructions received by main memory 506 mayoptionally be stored on storage device 510 either before or afterexecution by processor 504.

Computer system 500 also includes a communication interface 518 coupledto bus 502. Communication interface 518 provides a two-way datacommunication coupling to a network link 520 that is connected to alocal network 522. For example, communication interface 518 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 518 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 518sends and receives electrical, electromagnetic or optical signals thatcarry digital data streams representing various types of information.

Network link 520 typically provides data communication through one ormore networks to other data devices. For example, network link 520 mayprovide a connection through local network 522 to a host computer 524 orto data equipment operated by an Internet Service Provider (ISP) 526.ISP 526 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 528. Local network 522 and Internet 528 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 520and through communication interface 518, which carry the digital data toand from computer system 500, are example forms of transmission media.

Computer system 500 can send messages and receive data, includingprogram code, through the network(s), network link 520 and communicationinterface 518. In the Internet example, a server 530 might transmit arequested code for an application program through Internet 528, ISP 526,local network 522 and communication interface 518.

The received code may be executed by processor 504 as it is received,and/or stored in storage device 510, or other non-volatile storage forlater execution.

5.0 Equivalents, Extensions, Alternatives and Miscellaneous

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. Thus, the sole and exclusive indicatorof what is the invention, and is intended by the applicants to be theinvention, is the set of claims that issue from this application, in thespecific form in which such claims issue, including any subsequentcorrection. Any definitions expressly set forth herein for termscontained in such claims shall govern the meaning of such terms as usedin the claims. Hence, no limitation, element, property, feature,advantage or attribute that is not expressly recited in a claim shouldlimit the scope of such claim in any way. The specification and drawingsare, accordingly, to be regarded in an illustrative rather than arestrictive sense.

What is claimed is:
 1. A computer-implemented method, comprising:identifying, during runtime execution of a data transaction thread, oneor more programmatic code markers associated with contextual data aboutthe data transaction thread interacting with one or more data tablesassociated with a database, the one or more data tables used toefficiently retrieve data from the database; determining, during runtimeexecution of the data transaction thread, the contextual data based onthe identified one or more programmatic code markers invoked by thedatabase in the data transaction thread; determining, during runtimeexecution of the data transaction thread, whether the contextual dataindicates a data corruption in one or more supporting data structuresassociated with the one or more data tables; and in response to adetermination that the contextual data indicates a data corruption inthe one or more supporting data structures associated with the one ormore data tables: identifying one or more corrupted supporting datastructures of the one or more supporting data structures using thecontextual data; and performing, during runtime execution of the datatransaction thread, a data corruption detection action associated withthe one or more corrupted supporting data structures.
 2. The method asrecited in claim 1, wherein the action comprises logging a call stacktrace associated with the data transaction thread and the datacorruption.
 3. The method as recited in claim 2, further comprisingcausing a presentation of one or more log records comprising one or moredata corruptions.
 4. The method as recited in claim 1, wherein theaction comprises failing the data transaction thread.
 5. The method asrecited in claim 1, further comprising: generating a callback hookassociated with the one or more supporting tables, wherein thecontextual data is determined using the generated callback hookassociated with the one or more supporting tables.
 6. The method asrecited in claim 1, wherein the action comprises allowing the datatransaction thread to execute one or more statements that modify the oneor more data tables.
 7. The method as recited in claim 1, wherein thecontextual data indicates the data corruption based on a queryassociated with the programmatic code markers returning no results. 8.One or more non-transitory computer readable media, storing one or moresequences of instructions, which when executed by one or more processorscause performance of: identifying, during runtime execution of a datatransaction thread, one or more programmatic code markers associatedwith contextual data about the data transaction thread interacting withone or more data tables associated with a database, the one or more datatables used to efficiently retrieve data from the database; determining,during runtime execution of the data transaction thread, the contextualdata based on the identified one or more programmatic code markersinvoked by the database in the data transaction thread; determining,during runtime execution of the data transaction thread, whether thecontextual data indicates a data corruption in one or more supportingdata structures associated with the one or more data tables; and inresponse to a determination that the contextual data indicates a datacorruption in the one or more supporting data structures associated withthe one or more data tables: identifying one or more corruptedsupporting data structures of the one or more supporting data structuresusing the contextual data; and performing, during runtime execution ofthe data transaction thread, a data corruption detection actionassociated with the one or more corrupted supporting data structures. 9.The one or more non-transitory computer readable media as recited inclaim 8, wherein the action comprises logging a call stack traceassociated with the data transaction thread and the data corruption. 10.The one or more non-transitory computer-readable media of claim 9, whichwhen executed by the one or more processors cause further performanceof: causing a presentation of one or more log records comprising one ormore data corruptions.
 11. The one or more non-transitory computerreadable media as recited in claim 8, wherein the action comprisesfailing the data transaction thread.
 12. The one or more non-transitorycomputer-readable media of claim 8, which when executed by the one ormore processors cause further performance of: generating a callback hookassociated with the one or more supporting tables, wherein thecontextual data is determined using the generated callback hookassociated with the one or more supporting tables.
 13. The one or morenon-transitory computer readable media as recited in claim 8, whereinthe action comprises allowing the data transaction thread to execute oneor more statements that modify the one or more data tables.
 14. The oneor more non-transitory computer readable media as recited in claim 8,wherein the contextual data indicates the data corruption based on aquery associated with the programmatic code markers returning noresults.
 15. A system, comprising: one or more computing processors; oneor more non-transitory computer readable media storing a program ofinstructions that is executable by the one or more computing processorsto perform: identifying, during runtime execution of a data transactionthread, one or more programmatic code markers associated with contextualdata about the data transaction thread interacting with one or more datatables associated with a database, the one or more data tables used toefficiently retrieve data from the database; determining, during runtimeexecution of the data transaction thread, the contextual data based onthe identified one or more programmatic code markers invoked by thedatabase in the data transaction thread; determining, during runtimeexecution of the data transaction thread, whether the contextual dataindicates a data corruption in one or more supporting data structuresassociated with the one or more data tables; and in response to adetermination that the contextual data indicates a data corruption inthe one or more supporting data structures associated with the one ormore data tables: identifying one or more corrupted supporting datastructures of the one or more supporting data structures using thecontextual data; and performing, during runtime execution of the datatransaction thread, a data corruption detection action associated withthe one or more corrupted supporting data structures.
 16. The system asrecited in claim 15, wherein the action comprises logging a call stacktrace associated with the data transaction thread and the datacorruption.
 17. The system as recited in claim 16, wherein the programof instructions is executable by a device to further perform causing apresentation of one or more log records comprising one or more datacorruptions.
 18. The system as recited in claim 15, wherein the actioncomprises failing the data transaction thread.
 19. The system as recitedin claim 15, wherein the program of instructions is executable by adevice to further perform: generating a callback hook associated withthe one or more supporting tables, wherein the contextual data isdetermined using the generated callback hook associated with the one ormore supporting tables.
 20. The system as recited in claim 15, whereinthe action comprises allowing the data transaction thread to execute oneor more statements that modify the one or more data tables.
 21. Thesystem as recited in claim 15, wherein the contextual data indicates thedata corruption based on a query associated with the programmatic codemarkers returning no results.